@andrii-i

1. What is the remaining work that needs to be done? Let's document this here so we have clear guidelines on when this can be merged.

2. Can you include more screenshots in your PR description?

3. If the chat backend fails, we should have some way of delivering the exception trace to the client. Can you include a screenshot showing the current UI for this?

@dlqqq Thank you for looking into this.

1. Current state of this PR / what I planned to implement initially: whatever config errors are present, initialize config manager with errors, save errors as instances of ConfigErrorModel, pass them to the front end as a part of serialized DescribeConfigResponse, reset problematic values to default accordingly to schema, show errors and/or warnings to the user on the welcome screen as MUI alert. I discussed this approach with @3coins and he made some good arguments that I agree with: users should not be able to edit config directly so there is no use in gracefully handling config errors other than lm or em id errors. We should allow config manager to fail unless it's lm or em id (already done). Instead it would be better to change how API AuthenticationError is handled:

• Change how API AuthenticationError is handled: modify handle_exc to handle API authentication errors and return a human-readable error instead of a stack trace as a Jupyternaut resonse.

  jupyter-ai/packages/jupyter-ai/jupyter_ai/chat_handlers/base.py

  Line 111 in 64e6daf

  async def handle_exc(self, e: Exception, message: HumanChatMessage):

I'm working on this now, looks much easier to implement that what I tried earlier. Will probably open a new PR as there are a lot of changes in this PR that won't be needed, will be able to update on the progress later today. Within this PR, I have refactored large ConfigManager._init_config function into sub-functions, that would also be good to merge.

Would also love to hear your thoughts and/or suggestions.

2. See (3).
3. Below is a screenshots of how exception trace is shown to the user in "current state" of this PR. Please note that I'm pivoting away from this. See below.

• Here is how API Authentication Error currently shown to the user:

• Here is a mockup of what I'm currently working on to achieve: